Discovery and integration of jini services in non-java clients

ABSTRACT

A system of forming a bridge between non Java services and a Jini (™) interface. A non Java service is encapsulated using special code which makes it look like a Java service. Other aspects are also automatically formed. The Java service is automatically published with a broker such as a Jini (™) broker.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of and claims priority toU.S. patent application Ser. No. 09/734,333, filed Nov. 30, 2000. Thedisclosure of the prior application is considered part of (and isincorporated by reference in) the disclosure of this application.

BACKGROUND

Jini (™) is an established specification which allows applicationservices to announce their availability dynamically. Users of servicescan dynamically find an application service using Jini. Examples caninclude services providing freight rates, stock quotes, price inventorylevels for products or modules (e.g., calculators) for applications.Jini (™) operates by registering services, and responding to clientinquiries about one of these services. Jini (™) also provides proxy codeto the client allowing the client to communicate with the services. Inthis way, Jini (™) acts as a broker between the client and the existingservices.

Jini (™) has been written in a way such that it can only be used byservices written in Java. Many non-Java services (“legacy” services),however exist. These services cannot operate through Jini (™).

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects will now be described in detail with referenceto the accompanying drawings.

FIG. 1 shows an operation of the bridge of the present system, formingan interface between non Java services and a Jini (™) broker;

FIG. 2 shows a flowchart of operation of the system;

FIG. 3 shows an example of encapsulating CORBA component.

DETAILED DESCRIPTION

The present application defines a bridge between non Java services and aclient which is requesting such services. More specifically, the bridgeprovides a code generator to generate a proxy code that wraps thenon-Java object, and hence enables communication between the client andthe service. A surrogate object publishes information about the serviceand proxy. The surrogate object maintains this information using theJini (™) protocol. In this way, Jini (™) can be used in its normal way,but can used as a broker for non-Java services. Jini stores the code, byindexing the code directly, or by indexing proxy code.

The current Jini (™) interface will register services which have a JavaApplication Programming Interface (“API”). Services without a Java APIcannot be registered with Jini (™). While the present applicationspecifically describes using Jini (™), it should be understood that anyservice requiring a Java API could be similarly used.

The operation is shown in FIG. 1. A Java service normally publishesitself or its proxy to Jini (™), along with a set of search attributesthat can be used by services that are searching among the services.According to the present system, a non Java service 100 is published,using a Java compliant “wrapper”, as described. The wrapper acts likeJava proxy code, and points to the non Java service, in the same waythat Java proxy code would point to the Java service.

A GUI (Graphical User Interface) allows a user to point and click thelocation of a service interface file representing the non-Javacomponent, here an ActiveX component. For example, this may be an OCXfile for an activeX component 100 as shown in FIG. 1. The point andclick operation is used to instruct the bridge 110 to publish theservice.

The bridge 110 operates as shown in the flowchart of FIG. 2. At 200, thebridge performs run-time introspection of the service component 100. At210, the bridge identifies the methods/functionality within the service.This can use dynamic inspection and/or keywords, metatags, or otherkinds of application inspection. At 220, these results are stated as alist of different functionalities and other relevant information. FIG. 1shows the functionalities graphically as 120. This list will be used toform the eventual code.

At 230, this system forms middle tier tunneling proxy code 140 to form abridge between the client and the service. Other information obtainedfrom introspection at 210 is used to generate search attributes. Theseform keywords which are used to supplement the keyword repository inJini (™). In addition to the keywords identified by introspection, auser may also specify additional keywords in the Graphical UserInterface (GUI).

Jini (™) stores the proxy objects and a set of search attribute objectsshown as 152, 154, shown in FIG. 1.

The Jini (™) service is shown as 150. A client, or a service-proxy forthe client, makes a call to the backend service wrapper object. Thewrapper object redirects the call to the actual Component Object Model(“COM”) or CORBA component. Each time such a call is made, the bridge110 generates code that redirects the calls to the service 100. Thegenerated code may be Java proxy code.

At 260, the bridge receives a Jini (™) lease object based on thesuccessful registration of the Jini (™) object. The lease object shownas 142 keeps the object definition up-to-date. The bridge renews thelease from time to time, thereby insuring up-to-date information in Jini(™).

A service is published to Jini (™) in the following way. First, theservice is serialized as a Java object, if it can be so serialized.Other, non Java compliant services are packaged as described above.Services which are incapable of being serialized into Jini (™) maypublish their proxies instead. Constraints such as heaviness, nativedependability, and the like may prevent the service from directlypublishing to Jini (™). The proxy is a serializable lightweight Javaobject that acts as the service delegate. The proxies act as middletiered objects allowing access of services on the back end. The objector proxy is sent to Jini (™), along with a set of search attributes.Once the Java objects have been transported to Jini (™), they aredelivered to clients responsive to notifications of service matches.

Another aspect is to allow publishing either Jini or non Jini services.Any service that is capable of serialized in itself, and publishingitself to Jini (™), would do so directly. This enables clients todirectly use the service objects.

Non Jini (™) services may not have a proxy, or such a proxy may need tobe generated as part of the Jini (™) registration process.

Certain distributed application environments allow services to registerwith them through an identifier. One example is a GUID key for COMcomponents.

As an example of operation, FIG. 3 shows how the system could publishand obtain different information. A service 300, e.g., a CORBA serviceis coupled to the code generator 305 which provides an wrapper aroundthe CORBA shown as 310. Once in the wrapper, the CORBA code appears tothe broker or proxy as Java code, i.e., it is no different like anyother Java application. At 315, the application is published with theJini (™) broker. FIG. 3B, shows a client, which is a non Java clientsuch as an Excel(™) client asking for services. At 330, the request forservices is also placed in a wrapper at 335 and placed to Jini (™). Jini(™) returns the request.

Although only a few embodiments have been disclosed in detail above,other modifications are possible.

1. A system comprising: a collection of clients that receive services; aclient/server broker configured to register application services thathave a first application programming interface and identify theregistered application services to the clients; a first applicationservice that has the first application programming interface and isconfigured to publish an announcement of an availability of the firstapplication service; a second application service that has a secondapplication programming interface and is configured to publish anannouncement of an availability of the second application service; and abridge configured to wrap the announcement of the availability of thesecond application service in a wrapper that is compliant with the firstapplication programming interface so that the client/server broker canregister both the first application service and the second applicationservice.
 2. The system of claim 1, wherein the bridge comprises a proxycode generator and is configured to wrap the announcement of theavailability of the second application service in the proxy code.
 3. Thesystem of claim 1, wherein the bridge is configured to inspect thesecond application service to identify functionality of the secondapplication service and to identify the functionality to theclient/server broker.
 4. The system of claim 3, wherein the bridge isconfigured to inspect the second application service using dynamicinspection.
 5. The system of claim 1, wherein the client/server brokeris configured to identify functionality of the registered applicationservices to the clients.
 6. The system of claim 1, further comprising amemory associated with the client/server broker, wherein the memoryincludes information describing the registered application services. 7.The system of claim 6, wherein the information describing the registeredapplication services comprises a keyword repository.
 8. The system ofclaim 1, wherein: the client/server broker comprises a Jini™ interface;the first application programming interface comprises a Java™application programming interface; and the second applicationprogramming interface comprises a non-Java™ application programminginterface.
 9. The system of claim 1, further comprising a thirdapplication service proxy that has the first application programminginterface and is configured to publish an announcement of anavailability of the first application service.
 10. A method comprising:inspecting an application service; identifying that the applicationservice has a functionality; forming proxy code describing theidentified functionality; and forming a bridge between the applicationservice and a client using the proxy code.
 11. The method of claim 10,wherein forming the proxy code comprises middle tier tunneling proxycode.
 12. The method of claim 10, wherein forming the proxy codecomprises forming Java™ proxy code.
 13. The method of claim 10, whereinforming the bridge between the application service and the clientcomprises registering the application service with a client/serverbroker.
 14. The method of claim 13, wherein: the client/server broker isconfigured to register application services that have a firstapplication programming interface; and registering the applicationservice comprises wrapping an announcement of an availability of theapplication service in a wrapper that is compliant with the firstapplication programming interface.
 15. The method of claim 14, furthercomprising receiving a lease object from the client/server brokerindicating that the application service has been registered.
 16. Themethod of claim 14, wherein: the client/server broker comprises a Jini™interface; and the first application programming interface comprises aJava™ application programming interface.
 17. The method of claim 10,further comprising: generating a collection of search attributes basedon results of inspecting the application service; and making thecollection of search attributes available to the client/server broker.18. The method of claim 10, wherein inspecting the application servicecomprises dynamically inspecting the application service.
 19. The methodof claim 10, wherein inspecting the application service comprisesidentifying a metatag associated with the application service.